Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-146

Text File | 1996-05-19 | 77KB | 2,256 lines

C.S.M.P. Digest             Sat, 11 May 96       Volume 3 : Issue 146

Today's Topics:

        3D Renderer Sources Available
        Bug in Sound.h that could cause YOUR game to crash
        C++ classes & handles
        Hiding the menubar
        How do I determine the directory of my application
        How to flush a file.
        Long Edit Items In Dialogs
        MacOS Queue Utilities sample code
        MacTCP Q: Finding the local host's IP address
        New Mac Programming Web Page
        QuickDraw GX : Developer info at the GX Fan Club
        QuickTime Music Architecture -- Long Delays in Playing Notes
        Temporary Heaps



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Gavriel State)
Subject: 3D Renderer Sources Available
Date: 19 Apr 1996 03:54:02 -0400
Organization: none

My WatRend scanline-based 3D rendering engine is available for
downloading at http://www.magmacom.com/~gav/

WatRend is portable, having run on Macintoshes, SGI machines,
x86 DOS, and Linux.  It supports both fixed-point and floating-point
math.

It reads Rend386 format .plg files.

Share and Enjoy.

--
     Gavriel State | Macintosh Software Engineer | Corel Corporation
- ------------------------------------------------------------------------
            I don't speak for Corel...at least, I usually don't.


---------------------------

>From Jamie Osborne <[e-mail]>
Subject: Bug in Sound.h that could cause YOUR game to crash
Date: Thu, 18 Apr 1996 15:28:03 -0800
Organization: Apple Computer, Inc.

There is a nasty bug in Sound.h where a function is returning a structure
instead of a long as declared in the header.  This can cause odd crashes on
some machines.  There will be a tech note out on it soon.

The way it's declared:
extern pascal long SndSoundManagerVersion(void)

The way it should be:
extern pascal NumVersion SndSoundManagerVersion(void)


Please edit your Sound.h file.  This bug doesn't evince itself immediately,
and cause cause interesting behaviors, such as crashing the second time you
run your app.  It has already bitten a couple of developers.

Take heed.


-Jamie Osborne
Sprocket Engineer, Apple Game Technology Group


+++++++++++++++++++++++++++

>From Hiep Dam <[e-mail]>
Date: Fri, 19 Apr 1996 00:35:26 -0700
Organization: Earthlink stinks - don't suscribe!

Jamie Osborne wrote:
>
> There is a nasty bug in Sound.h where a function is returning a structure
> instead of a long as declared in the header.  This can cause odd crashes on
> some machines.  There will be a tech note out on it soon.
>
> The way it's declared:
> extern pascal long SndSoundManagerVersion(void)
>
> The way it should be:
> extern pascal NumVersion SndSoundManagerVersion(void)
>
> Please edit your Sound.h file.  This bug doesn't evince itself immediately,
> and cause cause interesting behaviors, such as crashing the second time you
> run your app.  It has already bitten a couple of developers.
>
> Take heed.

Silly me. And all this time I thought it was a "feature"...

(not to mention all the time I spent trying to typecast a numversion to long
to numversion* to long* maybe to numversion** to *long etc. to get the
"feature" to work. Of course, it didn't work. And I thought it was me. Silly,
silly, silly. I will be looking for such "features" next time...)

Thanks for the info though.
--
Hiep "there's no 'Van' in my name" Dam
--
{ [e-mail]/[e-mail] }
--
"Programmer, debug thyself"


+++++++++++++++++++++++++++

>From [e-mail] (David Lawrence)
Date: Fri, 19 Apr 1996 09:46:51 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>, [e-mail] wrote:

> There is a nasty bug in Sound.h where a function is returning a structure
> instead of a long as declared in the header.  This can cause odd crashes on
> some machines.  There will be a tech note out on it soon.
>
> The way it's declared:
> extern pascal long SndSoundManagerVersion(void)
>
> The way it should be:
> extern pascal NumVersion SndSoundManagerVersion(void)
>
>
> Please edit your Sound.h file.  This bug doesn't evince itself immediately,
> and cause cause interesting behaviors, such as crashing the second time you
> run your app.  It has already bitten a couple of developers.
>
> Take heed.



It got me, too.

Note: this bug is only in the Universal Headers on CW8 and ETO 18.  The
prototypes were correct in CW7 / ETO 17 and earlier, and they are
supposedly fixed in the ETO 19 Universal Headers.


    David Lawrence
    Future Tense


+++++++++++++++++++++++++++

>From [e-mail] (Matthew Melmon)
Date: 22 Apr 1996 22:15:43 GMT
Organization: Apple Computer

In article <dalawren-1904960246510001@192.0.2.1>, [e-mail]
(David Lawrence) wrote:

> In article <[e-mail]>, [e-mail] wrote:
>
> > There is a nasty bug in Sound.h where a function is returning a structure
> > instead of a long as declared in the header.

> Note: this bug is only in the Universal Headers on CW8 and ETO 18.  The
> prototypes were correct in CW7 / ETO 17 and earlier, and they are
> supposedly fixed in the ETO 19 Universal Headers.

The change to long was intentional, and the result of a
misunderstanding about return values on the Power Macintoshes
fitting into registers.  It was set back to NumVersion as of
ETO 19.


---------------------------

>From David T Mcwherter <[e-mail]>
Subject: C++ classes & handles
Date: Tue,  9 Apr 1996 07:27:24 -0400
Organization: Freshman, Mathematics, Carnegie Mellon, Pittsburgh, PA

    I'm trying to write a C++ app, and everything's working rather
nicely, except for one little dilemna.
    I'd like to create my objects in handles, not pointers.
    I think know how to use the new function to return a pointer to a class,
        myClassPtr = new Class();
and when I do this, everything works nicely and my constructor gets
called.  Conversely, when I use delete, my destructor is called.
    Is there a way to put the object into (and conversely delete) a
macintosh relocatable handle so that all the C++ niceties still work
(ie: constructor, destructor called automatically)?
    Also, what would be the conventions for locking the handle?  Would I
lock before a call to a function in the class, or could I call it
afterwards, inside the function?

PS: I'm using metrowerks codewarrior

Thanks,
-David McWherter
[e-mail]
http://abduction.res.cmu.edu

I want to die peacefully, in my sleep, like my grandfather, not
screaming, terrified, like his passengers.

+++++++++++++++++++++++++++

>From [e-mail] (James Jennings)
Date: Tue, 09 Apr 1996 18:20:52 -0700
Organization: Northwest Nexus Inc.

In article <[e-mail]>, David T Mcwherter
<[e-mail]> wrote:

>     Is there a way to put the object into (and conversely delete) a
> macintosh relocatable handle so that all the C++ niceties still work
> (ie: constructor, destructor called automatically)?

I did that once. I can send you my source if you're interested.

It's basically an "envelope" template class that handles the Handle. The
envelope has a Lock() and Unlock() method, and creates and disposes of the
Handle.

There are three key tricks:

1) In new.h there is a version of new() that doesn't allocate it's own
memory. It's called from the envelope's constructor like this:
   mObject = ::NewHandle(sizeof(Type));
   Type *t = new (*mObject) Type; // triggers Type's constructor...

2) It's possible to call an object's destructor directly. The envelope's
destructor does this.
   (*(Type**)mObject)->Type::~Type(); // trigger the destructor...
   ::DisposeHandle(mObject);

3) By supplying an operator->() you can make the envelope look like a
pointer to the object that is actually in the handle.
   Type * operator->(void) { return *(Type**)(theObject); }

Use it like this.
   ObjectHandle<A>   oha; // declare the envelope: A constructor called.
   oha.Lock();
   oha->Foo();   // calls A::Foo()
   oha.Unlock();

When oha goes out of scope it's destructor (and A's destructor) is called.

James

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 10 Apr 1996 14:53:59 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
David T Mcwherter <[e-mail]> wrote:

 > Is there a way to put the object into (and conversely delete) a
 > macintosh relocatable handle so that all the C++ niceties still work
 > (ie: constructor, destructor called automatically)?

No.

 > Also, what would be the conventions for locking the handle?  Would I
 > lock before a call to a function in the class, or could I call it
 > afterwards, inside the function?

My guess would be that you'd want to lock before making a call, since the
called code might be in another segment, and by the time the member
function executed, the 'this' pointer might already be invalid.

However, compilers won't cooperate with you on this one. They would have
to call HLock on their own, especially in the case of constructors, since
C++ syntax doesn't give you an opportunity to lock between the time the
object's memory block is allocated and its constructor is called. I
suppose you could write your own allocator which locked the handle just
after allocating it, but then all your constructors would be mysteriously
unlocking 'this' just before they returned, and heaven help you if you
ever forgot.

You CAN put SOME objects in handles, but you only get to use a sub-set of
C++ functionality with such objects. There's a section on this in one of
your compiler manuals.

To learn more about why you can't do real C++ with handle objects, check out:

    <URL:http://dev.info.apple.com/technotes/tn1009.html>

- -

  Pete Gontier, Integer Poet, Apple Macintosh Developer Technical Support

  work      mail  <mailto:[e-mail]>
  personal  mail  <mailto:[e-mail]>
  personal  web   <http://www.ccnet.com/~gurgle>
  work      web   <http://dev.info.apple.com/dts.html>

+++++++++++++++++++++++++++

>From "Etay Bogner" <[e-mail]>
Date: 11 Apr 96 14:47:28 +0000
Organization: Princeton Plasma Physics Laboratory

Just derive it from HandleObject, an internal "class" that metrowerks has
for backward compatibility with old MacApp's I guess.

Besides that I guess that it acts as a PascalObject rather than a C++
object in that that you have to supply an "Initialize" method that will do
the actual construction.

Anyway, try it and find out.

Etay.
- -------------------------------------------------
This message was created and sent using the Cyberdog Mail System
- -------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Fri, 12 Apr 1996 21:55:16 -0400
Organization: Tulip Software

In article <[e-mail]>, David T Mcwherter
<[e-mail]> wrote:

>     I'd like to create my objects in handles, not pointers.

Most Macintosh C++ compilers support a non-standard extension, which
provides a builtin class called HandleObject. [I'm not positive about the
spelling.] Simply derive your classes from this and you will get what you
want. The compiler takes care of most of the problems of using handles for
objects.

>     Also, what would be the conventions for locking the handle?  Would I
> lock before a call to a function in the class, or could I call it
> afterwards, inside the function?

Typically, one does not lock handle based objects. In principle, you don't
know that they are implemented as handles and don't have a supported way
to obtain the actual handle. (Of course, we all know how to do it, but we
shouldn't.)

The compiler automatically dereferences twice for every access to a field.
This means that the handle doesn't need to be locked. The only caveat is
that you can't pass pointers to fields as parameters to functions. Doing
so causes nasty and unpredictable crashes. You also cannot use multiple
inheritance with handle based objects.

BTW: I don't recommend doing this. The support is there to enable
compilation of old versions of MacApp. Even MacApp has migrated away from
handles and instead uses a much more efficient memory allocation scheme. I
generally find that the default new and delete commands (usually
implemented using malloc and free) do better than handles.

- --------------------
Ed Anson
Tulip Software
Andover, MA 01810   Check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Deirdre)
Date: Sat, 13 Apr 1996 11:39:05 -0400
Organization: Not hardly

In addition to everything that's been said on this, it occurs to This
Humble Person that one might want to create a block of objects as one
discrete handle. For one thing, when you allocated it you could HLockHi
and, when needed, do the same again.

For example, if you had an LSingleDoc which has an LWindow and an LFile
and you know this specific window will have ten objects of known size, you
could allocate it as one contiguous block. It could allocate other stuff
too if it needed it.

It would be a nightmare to figure out, but the group allocation idea does
have some merits. I would expect that you'd keep it locked most of the
time, but if you had problems with fragmenting the ability to move the
block could be a plus.

Just a thought.

_Deirdre

http://www.sover.net/~deirdre


+++++++++++++++++++++++++++

>From Paulo Casanova <[e-mail]>
Date: Sun, 14 Apr 1996 16:14:17 +0000
Organization: Instituto Superior Tecnico


> In addition to everything that's been said on this, it occurs to This
> Humble Person that one might want to create a block of objects as one
> discrete handle. For one thing, when you allocated it you could HLockHi
> and, when needed, do the same again.
[...]
> It would be a nightmare to figure out, but the group allocation idea
does
> have some merits. I would expect that you'd keep it locked most of the
> time, but if you had problems with fragmenting the ability to move the
> block could be a plus.
>
> Just a thought.
>
> _Deirdre

  I really don't think it would be that complicated. If you have an
object of type A 2 objects of type B you could make:

typedef struct
{
  A a;
  B, b1, b2;
} x;

  Then allocated 1 struct of type x and call the constructors... doesn't
sound complicated to me (only sounds very little cientific...)

Paulo

- ----------------------------------------------------------------------------
All rights reserved by the author. Unauthorised copying, hiring, lending or
broadcasting of this message prohibited. Exception: you can use my text for
replys to me or to the place where I have posted the message.
- ----------------------------------------------------------------------------



+++++++++++++++++++++++++++

>From Paulo Casanova <[e-mail]>
Date: Mon, 15 Apr 1996 20:21:09 +0000
Organization: Instituto Superior Tecnico

> What I meant (that was a nightmare) was that if you had pointers to stuff
> in this block and the block moved....well you'd have to find a way to
> account for that. You could have a msg_BlockMoving or some such that
> trickled through the appropriate places though.

  Yes, but supposed you had locked the handle and in that case you had no
problems with pointers. Of course you could unlock the handle in specific
cases and had to findout an "information" mechanism. Doesn't sound very,
very complicated. But it's not simple, anyway...

Paulo

- ----------------------------------------------------------------------------
All rights reserved by the author. Unauthorised copying, hiring, lending or
broadcasting of this message prohibited. Exception: you can use my text for
replies to me or to the place where I have posted the message.
- ----------------------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Deirdre)
Date: Sun, 14 Apr 1996 21:49:01 -0400
Organization: Not hardly

What I meant (that was a nightmare) was that if you had pointers to stuff
in this block and the block moved....well you'd have to find a way to
account for that. You could have a msg_BlockMoving or some such that
trickled through the appropriate places though.

_Deirdre

In article <[e-mail]>,
Paulo Casanova <[e-mail]> wrote:

> I really don't think it would be that complicated. If you have an
> object of type A 2 objects of type B you could make:

http://www.sover.net/~deirdre

+++++++++++++++++++++++++++

>From [e-mail] (Deirdre)
Date: Mon, 15 Apr 1996 18:37:34 -0400
Organization: Not hardly

Right, but I was talking about a chunk of objects in one handle. Do you
know every object that knows where your object is and can you update their
reference?

This is the issue as I see it. Not simple.

_Deirdre

In article <[e-mail]>,
Paulo Casanova <[e-mail]> wrote:

> Yes, but supposed you had locked the handle and in that case you had no
> problems with pointers. Of course you could unlock the handle in specific
> cases and had to findout an "information" mechanism. Doesn't sound very,
> very complicated. But it's not simple, anyway...

http://www.sover.net/~deirdre


+++++++++++++++++++++++++++

>From Paulo Casanova <[e-mail]>
Date: Tue, 16 Apr 1996 16:13:26 +0000
Organization: Instituto Superior Tecnico


> Right, but I was talking about a chunk of objects in one handle. Do you
> know every object that knows where your object is and can you update their
> reference?
>
> This is the issue as I see it. Not simple.
>
> _Deirdre

  Suppose you create a handle with n objects. Instead of referencing each
object with a pointer, you could reference it with a handle and
(possibly) an index.
  If you want to call the object all you had to do is to lock the handle
and call it. You don't have to lock it if you're sure no memory will move.

  The best way do implement this is directly by the compiler. It is
slower but it would be very memory-friendly.
  If I'm not mistaken, THINK C 6.0 implements objects as a C extension
and allows you to do this.

  Obvioulsy a C++ program like this is very inneficient (think about
having to lock a handle each time you want to call an object's method...)

  What I would suggest is somehow different: the program would create
only objects in the application's heap. Each object created (as a mac
locked handle - each object would have to overload the new operator) would
"register" itself in a "central" database.
  There would be a handle with all pointers to all objects and there
would be nothing else in the heap (except some handles if you wish).
  When the program runs out of memory (probably due to memory
fragmentation), every object's handle is released and CompactMem() is
called. Since everything in the heap are handles the heap would now be
perfecly defragmented. Since we had in the "main" database all pointers
of objects and all handles to them we know the old values of the
pointers, the new values of the pointers and were every obejct is.
  Now we would lock every object again and give each object a message to
update it's pointers. Then, each object would search in it's database all
pointers it has and updates them all. After this, all pointers point to
correct memory locations... how about this?

Paulo

- ----------------------------------------------------------------------------
All rights reserved by the author. Unauthorised copying, hiring, lending or
broadcasting of this message prohibited. Exception: you can use my text for
replies to me or to the place where I have posted the message.
- ----------------------------------------------------------------------------



+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Tue, 16 Apr 1996 12:05:40 GMT
Organization: Network Analysis Ltd

In article <[e-mail]>,
[e-mail] (Deirdre) wrote:

> For example, if you had an LSingleDoc which has an LWindow and an LFile
> and you know this specific window will have ten objects of known size, you
> could allocate it as one contiguous block. It could allocate other stuff
> too if it needed it.

If there is a known, fixed number, why not simply embed the 10 objects in
your LWindow object? Then when you allocate the latter, you allocate the
10 embedded objects as well. Or am I missing something?

--
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!britain.eu.net!nan!sw
Phone: [phone]                              Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Lay)
Date: Wed, 24 Apr 1996 09:58:08 +0100
Organization: DAMTP, Cambridge University

All this talk of C++ classes and handles reminded me of some code that I
wrote a long time ago (but have maintained every now and then for years).
I've never liked the idea of the 'hidden' implementation and, at the time,
wasn't confident enough with templates (and nor was my compiler) to
produce an elegant 'Handle envelope' solution like one of the previous
posters.

As a result of this discussion I went back and looked at the code for the
class which provides 'handle-based' objects.  When I first programmed in
C++
I naively assumed that the pointer returned by the allocator was the
pointer that I was using for my object.  When multiple inheritance came
along I realised my mistake but I didn't get round to upgrading the code
to cope until sometime last year.

A feature which would be nice is the ability to allocate whole arrays of
objects using one handle - sadly CW7 doesn't allow my approach to be
trivially extended to do this.  On the other hand, I did 'work in' support
for using temporary memory.

I've recently got round to the process of documenting my code (I know, I
know...) and so, for what it's worth, I've stuck a page up on the web from
where it can be seen:

http://www.amtp.cam.ac.uk/icrd/SCL/

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Steve Lay                                ICRD Group (Cambridge)

email:  [e-mail]                           DAMTP
WWW:    http://www.amtp.cam.ac.uk/icrd/           Silver Street
Phone:  [phone]                                Cambridge
Fax:    [phone]                                  CB3 9EW
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------

>From [e-mail] (Javier Alvarado)
Subject: Hiding the menubar
Date: 20 Apr 1996 08:09:34 GMT
Organization: Cal Poly Computer Science Dept.

What do I have to do to hide the menubar? I have tried setting the menubar
height to zero and then calling InvalMenubar() but it isn't erased.

Thanks for any help.


+++++++++++++++++++++++++++

>From [e-mail]
Date: Sat, 20 Apr 96 07:42:40 CST
Organization: Mouse Hole BBS

You have to add the freed-up space to whatever window you'd like to cover up the
menu bar with. Apple has an excellent example of this at their ftp site!!


Josh


Mouse Hole Server - Des Moines Iowa

+++++++++++++++++++++++++++

>From Steve Makohin <[e-mail]>
Date: 21 Apr 1996 19:54:33 GMT
Organization: Water's Edge Software

In article <4la63u$[e-mail]> Javier Alvarado,
[e-mail] writes:
>What do I have to do to hide the menubar? I have tried setting the menubar
>height to zero and then calling InvalMenubar() but it isn't erased.

What you are missing is adding the menu bar's region to your "gray
region" and invalidating the area that used to be under your menu bar.

If you want to hide the menu bar in one line of code (and have everything
work flawlessly), peek into the Tools Plus 3.0 (application development
libraries) evaluation kit on the nets. Tools Plus was rated 4 stars by
Macworld magazine.

-Steve Makohin
 Water's Edge Software

- -------
For a fast reply, send an email to: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Greg Bolsinga)
Date: Mon, 22 Apr 1996 00:48:46 -0500
Organization: Lo Fi Software

If you have Quicktime 2.1 installed, there's now an API for it. I don't
remember the name however.

And as a really cool thing: if you ask for say, 640x480, and a multisync
monitor is attached, and at a different screen ratio than the one you ask
for, it will change the screen ratio for you when it hides the menu bar!

Greg Bolsinga

--
Greg Bolsinga
[e-mail]
What's a Theremin?


+++++++++++++++++++++++++++

>From [e-mail] (Phil Nasadowski)
Date: 22 Apr 1996 21:32:21 GMT
Organization: None

In article <[e-mail]>, [e-mail] wrote:

> You have to add the freed-up space to whatever window you'd like to
cover up >the
> menu bar with. Apple has an excellent example of this at their ftp site!!

Which makes me wonder why Apple doesn't just make a stupid toolbox routine
to do this - I mean, it's not like it would never be called (and a lot
more useful than that PackBits() one, I STILL can't figure out what the
heck that does...)
I think by now (and for the last 5 years), getting rid of the menubar has
become and acepted thing on the Macintosh.  Why can't Apple just give us
more useful routines for real stuff like hideing the menu bar..


+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Tue, 23 Apr 1996 11:10:54 -0500
Organization: Groupimage, inc.

In article <4la63u$[e-mail]>,
[e-mail] (Javier Alvarado) wrote:

> What do I have to do to hide the menubar? I have tried setting the menubar
> height to zero and then calling InvalMenubar() but it isn't erased.
>

This has got to be the #1 FAQ.

Setting the menu bar height to zero isn't enough, since the grayRegion
(the desktop) requires to be grown (and shrunk back when re-showing the
mbar) so that it can draw where the menu bar was before.

In the following code, you'll see what's required for you to properly
change the menu bar height.

(Most obviously, this code is out of my own framework, and you'll have
play with it a bit, since you do not have the class' definition.  Though,
the basics of the code you need is there.)

void    TMenuManager::HideMenuBar   (void) {
    Rect        mBarRect    =   {0,0,0,0};
    RgnHandle   grayRegion  =   nil;

    if (!this->fMBarHidden) {
        this->fOldMBarHeight    =   LMGetMBarHeight();

        LMSetMBarHeight(0);

        SetRect(    &mBarRect,
                    qd.screenBits.bounds.left,
                    qd.screenBits.bounds.top,
                    qd.screenBits.bounds.right,
                    qd.screenBits.bounds.top + this->fOldMBarHeight);

        this->fMBarRgn  =   NewRgn();

        RectRgn(this->fMBarRgn, &mBarRect);

        grayRegion = GetGrayRgn();

        UnionRgn(grayRegion, this->fMBarRgn, grayRegion);

        PaintOne(nil, this->fMBarRgn);

        this->fMBarHidden   =   true;

        DrawMenuBar();
    }
}

void    TMenuManager::ShowMenuBar   (void) {
    RgnHandle       grayRegion  =   nil;

    if (this->fMBarHidden) {
        LMSetMBarHeight(this->fOldMBarHeight);

        grayRegion  =   GetGrayRgn();

        DiffRgn(grayRegion, this->fMBarRgn, grayRegion);

        DisposeRgn(this->fMBarRgn);

        this->fMBarRgn  =   nil;

        this->fMBarHidden   =   false;

        DrawMenuBar();
    }
}

--
Martin-Gilles Lavoie

[CYRNFR QB ABG ZVK BE BGUREJVFR NYGRE GUR OVGF VA GUVF ZRFFNTR.]

+++++++++++++++++++++++++++

>From Duane Maxwell <[e-mail]>
Date: Tue, 23 Apr 1996 15:58:40 -0700
Organization: Gryphon Software Corporation

>Which makes me wonder why Apple doesn't just make a stupid toolbox routine
>to do this - I mean, it's not like it would never be called

Wonder no more - there is such a call in QuickTime 2.1.  It takes care of the menu bar
and the control strip.  I belive Sprockets also supports such a call.


+++++++++++++++++++++++++++

>From [e-mail]
Date: Wed, 24 Apr 1996 20:23:29 -0700
Organization: CCnet Communications (510-988-7140 guest)

In article <[e-mail]>,
[e-mail] (Phil Nasadowski) wrote:
>Which makes me wonder why Apple doesn't just make a stupid toolbox routine
>to [hide the menu bar]

QuickTime 2.1 and later contains a call to hide the menu bar, control
strip, and any other "stuff" that might interfer with a movie (or game,
etc.)  See the QuickTime 2.1 documentation for details.

---------------------------

>From [e-mail] (Brian Forney)
Subject: How do I determine the directory of my application
Date: Thu, 18 Apr 1996 22:33:27 -0400
Organization: University of Michigan, College of Engineering

Hi. I'd like to read a file that's in the same directory as my application
without using the standard file dialog package. Is there some way to do
this? I've looked at the Inside Macintosh File volume, but I haven't found
anything that would even hint at this. If there's a FAQ on this, please
point me to it.

Thanks,
Brian Forney
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dave Hina)
Date: Fri, 19 Apr 1996 09:10:57 -0700
Organization: SAIC at NRaD

In article <[e-mail]>,
[e-mail] wrote:

 > Hi. I'd like to read a file that's in the same directory as my application
 > without using the standard file dialog package. Is there some way to do
 > this? I've looked at the Inside Macintosh File volume, but I haven't found
 > anything that would even hint at this. If there's a FAQ on this, please
 > point me to it.
 >
Try using the Process Manager's GetProcessInfo() to obtain the FSSpec of your
application. Then replace the file name with that of the file you want to read.

Dave

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+                            Dave Hina                              +
+                          SAIC at  NRaD                            +
+                          San Diego, CA                            +
+              email: [e-mail], [e-mail]             +
+                 p: 619-553-5187   f: 619-553-4732                 +
+                        Opinions == mine!                          +
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


+++++++++++++++++++++++++++

>From [e-mail] (Allan Evans)
Date: Fri, 19 Apr 1996 09:35:33 -0500
Organization: SicolaMartin

In article <[e-mail]>, Brian
Forney ([e-mail]) wrote:

> Hi. I'd like to read a file that's in the same directory as my application
> without using the standard file dialog package. Is there some way to do
> this? I've looked at the Inside Macintosh File volume, but I haven't found
> anything that would even hint at this. If there's a FAQ on this, please
> point me to it.
>
> Thanks,
> Brian Forney
> [e-mail]

Try PBDTGetAPPL (IM Mac Toolbox Essentials, Ch. 7) - one of the parameters
returned is the parent directory ID, which you could then use to create a
filespec with FSMakeFSSpec to open your file. Hope that helps...

- Allan

--
Allan Evans     [e-mail],   [e-mail]
Interactive Programmer, SicolaMartin  -  Austin, TX, USA
[phone]
Ask me about Magnet...
"No matter where you go, there you are.' - BB

+++++++++++++++++++++++++++

>From [e-mail] (Brian Zuk)
Date: Fri, 19 Apr 1996 13:07:58 -0400
Organization: Telerama Public Access Internet, Pittsburgh, PA

  I use this at startup.

Brian Zuk

   SInt16            vRefNum;
   WDPBRec           wdr;
   FSSpec            spec;

   GetVol(NULL, &vRefNum);
   wdr.ioNamePtr = spec.name;
   wdr.ioVRefNum = vRefNum;
   wdr.ioWDIndex = 0;
   wdr.ioWDProcID = 0;
   wdr.ioWDVRefNum = 0;
   PBGetWDInfoSync(&wdr);

   spec.vRefNum = wdr.ioWDVRefNum;
   spec.parID = wdr.ioWDDirID;
   PLstrcpy(spec.name, LMGetCurApName());


+++++++++++++++++++++++++++

>From [e-mail] (Rob Friefeld)
Date: Sat, 20 Apr 1996 20:46:15 -0800
Organization: Delta Internet Services, Anaheim, CA

In article <[e-mail]>,
[e-mail] (Allan Evans) wrote:

>In article <[e-mail]>, Brian
>Forney ([e-mail]) wrote:
>
>> Hi. I'd like to read a file that's in the same directory as my application
>> without using the standard file dialog package. Is there some way to do
>> this? I've looked at the Inside Macintosh File volume, but I haven't found
>> anything that would even hint at this. If there's a FAQ on this, please
>> point me to it.

Here is what I use.

/*******************************************************************************
//
//    Get the current process file location.
//       On error, vRefNum and dirID contain 0 (default directory)
//
*******************************************************************************/
OSErr WhereAmI(short* vRefNum, long* dirID)
{
   ProcessInfoRec    tempInfo;
   ProcessSerialNumber  PSN;
   FSSpec            procSpec;
   OSErr          err;

   PSN.lowLongOfPSN = kCurrentProcess; // First, find out where our app is
   PSN.highLongOfPSN = 0;

   tempInfo.processInfoLength = sizeof(ProcessInfoRec);
   tempInfo.processName = nil;
   tempInfo.processAppSpec = &procSpec;

   if ((err = GetProcessInformation(&PSN, &tempInfo)) == noErr) {
      *vRefNum = procSpec.vRefNum;
      *dirID = procSpec.parID;
   }
   else {
      *vRefNum = 0;
      *dirID = 0;
   }
   return err;
}
--
Rob Friefeld   Long Beach, CA    [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Tue, 23 Apr 1996 11:04:29 -0500
Organization: Groupimage, inc.

In article <[e-mail]>,
[e-mail] wrote:

> Hi. I'd like to read a file that's in the same directory as my application
> without using the standard file dialog package. Is there some way to do
> this? I've looked at the Inside Macintosh File volume, but I haven't found
> anything that would even hint at this. If there's a FAQ on this, please
> point me to it.
>

A quick and dirty way is to call

    anErr = FSMakeFSSpec(0, 0L, "\p:", &spec);

early in your application startup.  However, this will not always return
your application's directory, depending on how the user launched the
application.

A better (ie, more complicated) way of getting this information is through
the Process Manager.  Simply call

    ProcessInfoRec  info;
    FSSpec          myAppSpec;

    info.processAppSpec = &myAppSpec;

    anErr = GetProcessInformation(kCurrentProcess, &info);


and find your application's FSSpec in 'myAppSpec'.

--
Martin-Gilles Lavoie

[CYRNFR QB ABG ZVK BE BGUREJVFR NYGRE GUR OVGF VA GUVF ZRFFNTR.]


+++++++++++++++++++++++++++

>From "Edward Voas" <[e-mail]>
Date: 25 Apr 96 02:09:13 +0000
Organization: Shore.Net/Eco Software, Inc; ([e-mail])

>Many people recommend using the Process Manager (call FrontProcess() to
get
>your Process ID, then call GetProcessInformation(), which returns, among
>other things, the FSSpec of your application).
>

This should really be a GetCurrentProcess call, or just use kCurrentProcess
in the call to GetProcessInformation. Just in case.

Ed Voas

---------------------------

>From [e-mail] (Jim Nash)
Subject: How to flush a file.
Date: Wed, 17 Apr 1996 14:34:53 -0400
Organization: SRS

How to flush a file.

I have critical data that needs to be saved to disk even if there is a
system crash.  I have used PBFlushFileSync with no luck.  My question is,
how do you make sure that, after a FSWrite command, data is written to
disk and that volume information is updated.  When I open the file after a
simulated crash, the end of file pointer has not been advanced.  Here are
the details of the test:

1.  Open data file.

2.  Use FSWrite.

3.  Use PBFlushFileSync.

4.  Repeat 2 and 3 in a loop and manually turn the computer's power off or
hit the restart button.

5.  Restart the computer and open the data file.

6.  Try to read data with FSRead.  End of file = 0.


The documentation for PBFlushFileSync says that volume information is
written to the disk.  What is wrong?  How does one *really* flush file
information?

I am using System 7.5.1 on a Mac IIfx.

- Jim

____________________________________________________________________
James W. Nash, Synergistic Research Systems
4409 Mahan Court, Silver Spring, MD 20906, USA
[phone], fax: [phone]
____________________________________________________________________


+++++++++++++++++++++++++++

>From [e-mail] (JovianSoft)
Date: 17 Apr 1996 19:52:50 -0400
Organization: America Online, Inc. (1-800-827-6364)

If you're interested in a velveeta answer, you could always OPEN, APPEND,
AND CLOSE the file in question. That will ensure that it gets written as
soon as it's called.

Not particularly speedy, or efficient. Like I said, cheesey.

HTH


+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: Wed, 17 Apr 1996 20:50:11 -0600
Organization: MindVision Software

In article <[e-mail]>, [e-mail]
(Jim Nash) wrote:

> How to flush a file.
>
> I have critical data that needs to be saved to disk even if there is a
> system crash.  I have used PBFlushFileSync with no luck.  My question is,
> how do you make sure that, after a FSWrite command, data is written to
> disk and that volume information is updated.  When I open the file after a
> simulated crash, the end of file pointer has not been advanced.  Here are
> the details of the test:
>
> 1.  Open data file.
>
> 2.  Use FSWrite.
>
> 3.  Use PBFlushFileSync.
>
> 4.  Repeat 2 and 3 in a loop and manually turn the computer's power off or
> hit the restart button.
>
> 5.  Restart the computer and open the data file.
>
> 6.  Try to read data with FSRead.  End of file = 0.
>
>
> The documentation for PBFlushFileSync says that volume information is
> written to the disk.  What is wrong?  How does one *really* flush file
> information?
>
> I am using System 7.5.1 on a Mac IIfx.

Open the file, size it accordingly, call _FlushVol (makes sure the file
information is written), do your writes with ioPosMode and'ed with 32
(indicates a request to not cache the write).

The problem you are having is that the data is being written out, but the
catalog has not been updated to indicate the file size.

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 18 Apr 1996 01:35:26 -0400
Organization: America Online, Inc. (1-800-827-6364)

>In article <[e-mail]>, [e-mail]
>(Jim Nash) wrote:
>
>> How to flush a file.
>>
>> I have critical data that needs to be saved to disk even if there is a
>> system crash.  I have used PBFlushFileSync with no luck.  My question
is,
>> how do you make sure that, after a FSWrite command, data is written to
>> disk and that volume information is updated.  When I open the file
after a
>> simulated crash, the end of file pointer has not been advanced.  Here
are
>> the details of the test:
>>
>> 1.  Open data file.
>>
>> 2.  Use FSWrite.
>>
>> 3.  Use PBFlushFileSync.
>>
>> 4.  Repeat 2 and 3 in a loop and manually turn the computer's power off
or
>> hit the restart button.
>>
>> 5.  Restart the computer and open the data file.
>>
>> 6.  Try to read data with FSRead.  End of file = 0.
>>
>>
>> The documentation for PBFlushFileSync says that volume information is
>> written to the disk.  What is wrong?  How does one *really* flush file
>> information?
>>
>> I am using System 7.5.1 on a Mac IIfx.
>
>Open the file, size it accordingly, call _FlushVol (makes sure the file
>information is written), do your writes with ioPosMode and'ed with 32
>(indicates a request to not cache the write).
>
>The problem you are having is that the data is being written out, but the
>catalog has not been updated to indicate the file size.
>
>Steve Kiene
>MindVision Software

Steve's right. You can read more on this subject in the Macintosh
Technical Note "FL 16" which covers File Manager performance issues and
caching issues.

- Jim Luther


+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 18 Apr 1996 16:17:33 GMT
Organization: CoBase group, UCLA Department of Computer Science

In article <[e-mail]>, [e-mail] (Jim Nash) writes:
> How to flush a file.
>
> I have critical data that needs to be saved to disk even if there is a
> system crash.  I have used PBFlushFileSync with no luck.  My question is,
> how do you make sure that, after a FSWrite command, data is written to
> disk and that volume information is updated.  When I open the file after a
> simulated crash, the end of file pointer has not been advanced.  Here are
> the details of the test:
> [ stuff deleted ... ]

I think the call you need is FlushVol(). Try looking that up or waiting for
Jim Luther to correct my post :-).

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 20 Apr 1996 12:56:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

>In article <[e-mail]>, [e-mail]
(Jim Nash) writes:
>> How to flush a file.
>>
>> I have critical data that needs to be saved to disk even if there is a
>> system crash.  I have used PBFlushFileSync with no luck.  My question
is,
>> how do you make sure that, after a FSWrite command, data is written to
>> disk and that volume information is updated.  When I open the file
after a
>> simulated crash, the end of file pointer has not been advanced.  Here
are
>> the details of the test:
>> [ stuff deleted ... ]
>
>I think the call you need is FlushVol(). Try looking that up or waiting
for
>Jim Luther to correct my post :-).
>
>--Chris

Why would I correct a perfectly good answer? :-}

- Jim


+++++++++++++++++++++++++++

>From [e-mail] (Tony Nelson)
Date: Mon, 22 Apr 1996 14:49:13 -0400
Organization: The Internet Access Company

In article <[e-mail]>,
[e-mail] (Steve Kiene) wrote:

> Open the file, size it accordingly, call _FlushVol (makes sure the file
> information is written), do your writes with ioPosMode and'ed with 32
> (indicates a request to not cache the write).

This will cause physical i/o for each write call.  If you are doing a
bunch of writes all at once and then need to flush to disk, this will be
very slow (sort of like MacsBug's LOG command).  A faster way would be to
flush once at the end; _FlushVol will do the trick.

> The problem you are having is that the data is being written out, but the
> catalog has not been updated to indicate the file size.

Yep.  Just having the data on the disk isn't good enough if the disk
catalog says it isn't there!

> Steve Kiene
> MindVision Software
____________________________________________________________________
TonyN.:'                                              [e-mail]
      '


---------------------------

>From [e-mail] (Des Courtney)
Subject: Long Edit Items In Dialogs
Date: Sun, 21 Apr 1996 04:10:41 -0400
Organization: Flair Diversions

I'd like to be able to edit text in Dialogs that can get longer
  than 255 characters.  Since, for now anyway, there is only one
  edit field per dialog, I'm thinking about monkeying around with
  the dialog's "current" TERecord.  Will this work?  Or will I have
  to resort to coding a User Item?

Des "Finally Working On Something Again" Courtney
--
Flair Diversions is... Des Courtney, writer of cool Mac software
         Outpost Nexus, Ambiance, Icons for MICN, etc.
   mailto:[e-mail]   http://www.bright.net/~deslee/
      On The Newsgroup Scrapheap: rec.games.video.nintendo


+++++++++++++++++++++++++++

>From [e-mail] (Mark Phaedrus)
Date: Mon, 22 Apr 1996 15:13:49 -0700
Organization: Lycanthropes Anonymous

In article <[e-mail]>,
[e-mail] (Des Courtney) wrote:

>I'd like to be able to edit text in Dialogs that can get longer
>  than 255 characters.  Since, for now anyway, there is only one
>  edit field per dialog, I'm thinking about monkeying around with
>  the dialog's "current" TERecord.  Will this work?  Or will I have
>  to resort to coding a User Item?

     If all you want to do is get and set the text in edit text items,
then yes, it can be done.  Here's a stripped-down version of the code I'm
using to do this, which seems to be working just fine:

OSErr GetDString(const DialogPtr theDialog, const short ID, char * buf)
{
    Handle htext;
    short theType;
    Rect myRect;
    Size textsize;

    /* Get the item's info, including its TextEdit handle */
    GetDItem(theDialog,ID,&theType,&htext,&myRect);
    /* Sanity check here; make sure we're dealing with an editText item */
    theType = theType & ~itemDisable;
    if (theType != editText) {
        return(paramErr);
    }
    /* Find out how big the text is... */
    textsize = GetHandleSize(htext);
    /* ... and copy it into the buffer (overflow checking deleted as usual
       for sample code) */
    if (textSize) {
        BlockMove(*hText,buf,textsize);
    }
    buf[textSize] = '\0';
    return(noErr);
}

OSErr SetDString(const DialogPtr theDialog, const short ID, const char * buf)
{
    Handle htext;
    short theType;
    Rect myRect;
    OSErr err = noErr;
    GrafPtr port;

    GetPort(&port);
    SetPort(theDialog);
    GetDItem(theDialog,ID,&theType,&htext,&myRect);
    /* sanity check deleted from this one */
    /* Set the insertion point in the target item; this makes sure that it's
       the current item, which makes the Dialog Manager set it up
       properly */
    SelIText(theDialog,ID,0,0);
    /* Copy the text into the Dialog Manager's TextEdit handle */
    TESetText(buf,strlen(buf),((DialogPeek)theDialog)->textH);
    /* TextEdit and the Dialog Manager won't trigger a redraw when you do
       this; you've gotta do it yourself--fortunately we have the item's
       rectangle handy */
    InvalRect(&myRect);
    /* Set the selection point again (this one happens to set it to the end
       of the text); this forces the Dialog Manager to recognize the changes
       you've made to the TextEdit handle */
    SelIText(theDialog,ID,32767,32767);
    return(noErr);
}

     I hope this helps...

--
\o\ If you're interested in books/stories with transformation themes,\o\
 \o\please try <URL:http://www.halcyon.com/phaedrus/Menu.html>, or    \o\
 /o/anonymous-ftp to ftp.halcyon.com in /local/phaedrus/translist.    /o/
/o/ Comments and submissions to this list are always welcome.        /o/

+++++++++++++++++++++++++++

>From [e-mail] (Des Courtney)
Date: Wed, 24 Apr 1996 03:49:33 -0400
Organization: Flair Diversions

In article <[e-mail]>,
  [e-mail] (Mark Phaedrus) wrote:

)      If all you want to do is get and set the text in edit text items,
) then yes, it can be done.  Here's a stripped-down version of the code I'm
) using to do this, which seems to be working just fine:
)
[code saved]

Cool!  Thanks, I'll try it out next chance I get.

Des Courtney
--
Flair Diversions is... Des Courtney, writer of cool Mac software
         Outpost Nexus, Ambiance, Icons for MICN, etc.
   mailto:[e-mail]   http://www.bright.net/~deslee/
         On The Newsgroup Scrapheap: rec.arts.tv.mst3k

+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: 24 Apr 96 16:48:22 GMT
Organization: Applied BioSystems

In article <[e-mail]>,
[e-mail] (Des Courtney) wrote:

>I'd like to be able to edit text in Dialogs that can get longer
>  than 255 characters.  Since, for now anyway, there is only one
>  edit field per dialog, I'm thinking about monkeying around with
>  the dialog's "current" TERecord.  Will this work?  Or will I have
>  to resort to coding a User Item?

I think the only 255 character limit on editText items is in using
Get/SetDialogItem cause they only accept a Str255. Messing with the
TERecord directly should work. Just remember the TERecord is for all the
editText items in the dialog.

The problem is that even if this does work, it would seem that anything in
a dialog using more than 255 characters might need a scrollbar which would
be difficult to implement using the Dialog Manager's text handling.

You'd probably end up spending more time messing with the Dialog Manager
to get it working then you would to just create a user item in the dialog
and create your own TERecord.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 24 Apr 1996 18:50:35 -0700
Organization: Internet for the Olympic Peninsula

In article <SouthSide-2404960950010001@192.43.251.123>, [e-mail]
(Bob Bradley) wrote:

>In article <[e-mail]>,
>[e-mail] (Des Courtney) wrote:
>
>>I'd like to be able to edit text in Dialogs that can get longer
>>  than 255 characters.  Since, for now anyway, there is only one
>>  edit field per dialog, I'm thinking about monkeying around with
>>  the dialog's "current" TERecord.  Will this work?  Or will I have
>>  to resort to coding a User Item?
>
>I think the only 255 character limit on editText items is in using
>Get/SetDialogItem cause they only accept a Str255. Messing with the
>TERecord directly should work. Just remember the TERecord is for all the
>editText items in the dialog.
>
>The problem is that even if this does work, it would seem that anything in
>a dialog using more than 255 characters might need a scrollbar which would
>be difficult to implement using the Dialog Manager's text handling.
>
>You'd probably end up spending more time messing with the Dialog Manager
>to get it working then you would to just create a user item in the dialog
>and create your own TERecord.

One of the suggestions in Inside Mac boils down to:  if implementing a
dialog as a Dialog starts getting difficult, don't.  Use a real window
(built to look like a Dialog).  It's easier to deal with the events the
normal way than to deal with the Dialog Manager's "help".  See pages 6-16
and 6-17 in Inside Mac:  Macintosh Toolbox Essentials for some help in
deciding.

MacApp does almost all dialogs itself (StandardFile is an exception, as it
should be).  Even the simplest (it tends to do alerts using the Dialog
Manager, last I looked.  This is a source of annoyance to QuicKeys
(spelled wrong here) users.

   --John

--
  The primary cause of problems is solutions.
John W. Baxter    Port Ludlow, WA, USA     [e-mail]

---------------------------

>From Manabu Tokanaga <[e-mail]>
Subject: MacOS Queue Utilities sample code
Date: Fri, 26 Apr 1996 15:36:02 -0700
Organization: Aimnet Information Services

I would like to get some sample code in C or C++ illustrating how
to use the Queue Utility routines to handle MacOS queues.  Does
anyone have some they could send to me or know where I can get
some code examples?  I would appreciate hearing from anyone who
could help.  Thanks very much in advance...

Vic Hargrave
[e-mail]
Cyberspace, the final frontier.


+++++++++++++++++++++++++++

>From [e-mail] (Brian Zuk)
Date: Fri, 26 Apr 1996 20:57:47 -0400
Organization: Telerama Public Access Internet, Pittsburgh, PA

In article <[e-mail]>, Manabu Tokanaga <[e-mail]>
wrote:

>I would like to get some sample code in C or C++ illustrating how
>to use the Queue Utility routines to handle MacOS queues.  Does
>anyone have some they could send to me or know where I can get
>some code examples?  I would appreciate hearing from anyone who
>could help.  Thanks very much in advance...
>
>Vic Hargrave
>[e-mail]
>Cyberspace, the final frontier.

Vic,
  I think I am answering the question you are asking.  Here goes...

QHdr    queue = { 0, NULL, NULL };

struct MyQueueElem
{
 MyQueueElem*     qLink;
 SInt16           qType;
 .... add what ever data you want to here
} ;

MyQueueElem*    qElem;

qElem = NewPtrClear(sizeof(MyQueueElem); // MUST use new or NewPtr
Enqueue((QElemPtr)qElem, &queue); // I may have these parameters reversed
...
MyQueueElem*    link = queue.qHead;

while(link != NULL)
{
 ...
 link = link->qLink;
}
...
Dequeue((QElemPtr)qElem, &queue);
DisposePtr((Ptr)qElem);

Brian Zuk

---------------------------

>From Nathaniel P Woods <[e-mail]>
Subject: MacTCP Q: Finding the local host's IP address
Date: Fri, 19 Apr 1996 13:15:52 -0400
Organization: Sophomore, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

What MacTCP call allows a program to obtain the current host's IP address?

Thanks in advance,
Nathaniel

+++++++++++++++++++++++++++

>From [e-mail] (Markus Maier)
Date: Sun, 21 Apr 1996 18:24:42 +0200
Organization: University Of Ulm

In article <[e-mail]>,
Nathaniel P Woods <[e-mail]> wrote:

> What MacTCP call allows a program to obtain the current host's IP address?
>
> Thanks in advance,
> Nathaniel

The following code will do the job:
OSErr GetMyIPAddr(ip_addr *inAddr)
{
    struct GetAddrParamBlock    ipBlock;
    OSErr                        anErr;

    ipBlock.csCode = ipctlGetAddr;
    ipBlock.ioCRefNum = mMacTCPRefNum;

    anErr = PBControlSync((ParmBlkPtr)&ipBlock);
    *inAddr = ipBlock.ourAddress;

    return anErr;
}


Markus




---------------------------

>From [e-mail] (Y. Tony Lee)
Subject: New Mac Programming Web Page
Date: Sun, 21 Apr 1996 23:46:54 -0500
Organization: Boston University

Hello,
   I have constructed a web site filled with links related to Mac
programming.  The URL is:
http://med-amsa.bu.edu/Pharmacology/pharm.people/Lee/MacProg.html

I hope the page helps all Mac Programmers.

Tony

--
Home Page:
http://med-amsa.bu.edu/Pharmacology/pharm.people/Lee/Lee.html
Mac Developer Central:
http://med-amsa.bu.edu/Pharmacology/pharm.people/Lee/MacProg.html

---------------------------

>From [e-mail] (Kenneth Trueman)
Subject: QuickDraw GX : Developer info at the GX Fan Club
Date: Sun, 21 Apr 1996 22:55:42 -0400
Organization: QuickDraw GX Fan Club

In the last few months, I have dedicated a section of the GX Fan Club web
site to developer information about QuickDraw GX.  There you will find
links to GX-speicifc web resources, develop articles, Apple DTS technotes,
Tech Q & As, and more.

There is a subscription form if you would like to come join the more than
160 members of the GX developers mailing list.   The archives of the
GXLists are now searchable via the Web too ...

I have also set up a page dedicated to GX and the upcoming WWDC ... come
see who's going to WWDC this year ...

http://www.ixmedia.com/quickgx/gxdev.html

doing what I can to help out GX ...

Kenneth
glad to be back on UseNet ... thanks Geoff ...

--
[e-mail]
Hungry for GX info ? Check out the QuickDraw GX Fan Club pages :
<http://www.ixmedia.com/quickgx/quickgx.html>
For more info on the QuickDraw GX Fan Club, send a message to [e-mail]

---------------------------

>From [e-mail] (Charlie Kilpatrick)
Subject: QuickTime Music Architecture -- Long Delays in Playing Notes
Date: Tue, 23 Apr 1996 16:01:57 -0400
Organization: Wesleyan University

We have been experiencing problems using QuickTime Music Architecture on
PowerPCs.  There can be increasingly long delays between the time QTMA is
told to generate a note, and when the note is actually heard.

Problem Description:
   To test out this problem, we have been running an application called
"Instrument Picker", an application provided on Apple's Developer CD
Series.  This application lets you select an instrument and click on an
onscreen keyboard to generate notes.  When this application is first
opened, there is no delay whatsoever between clicking on the keyboard and
hearing the note.  As time progresses, a delay time between clicking &
hearing steadily increases.  The rate seems to be about 2 seconds of delay
for every 3-4 minutes that the application is open.  Quiting the
application and reopening it will make the delay time between clicking &
hearing notes reset to zero, only to increase again.  This delay is
critically unacceptable because we are developing an application that
sends UDP messages to computers across a network to have them play in
sync.

   What is puzzling about this problem is that only exists on certain
computers, unpredictibly -- we have experienced it mainly on 7100/80's
running either 7.5.1 or 7.5.3.  7100/66's are safer, and a Quadra does not
exhibit the problem.  The relevant extensions we have loaded are QuickTime
2.1, QuickTime™ Musical Instruments 2.1, Sound Manager 3.1, QuickTime
PowerPlug.

   We would be extremely grateful for any help or to hear from anyone who
has experienced similar problems to help us narrow down the particular
extension or whatnot that is causing this problem.

--
Charlie Kilpatrick
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Thu, 25 Apr 1996 13:32:10 -0700
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Charlie Kilpatrick) wrote:

> We have been experiencing problems using QuickTime Music Architecture on
> PowerPCs.  There can be increasingly long delays between the time QTMA is
> told to generate a note, and when the note is actually heard.

Yes, this is true. It's been fixed in the next release of QuickTime.

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."


---------------------------

>From [e-mail] (David B. Zwiefelhofer)
Subject: Temporary Heaps
Date: Thu, 11 Apr 1996 19:18:36 -0500
Organization: Utility Reduction Specialists, Inc.

I have a faceless background application that needs to be running all the
time. I want it to take up very little RAM while it is not actively doing
it's thing. Unfortunately, it's thing requires anywhere from 150K to  1.5M
so I'd like to have it do it's thing in a temporary, disposable heap. I
know nothing of how this is done.

Can someone please give me a general run down on how to:

1) Allocate the heap.

2) Make GWorlds and allocate other toolbox structures in the new heap.

3) Anything else relevant to using temporary heaps.


Thanks much,

Dave

--
David B. Zwiefelhofer
Utility Reduction Specialists, Inc.
1605 Monroe Street, Suite 110
Madison, WI  53211-2052
[phone]
[phone] FAX

+++++++++++++++++++++++++++

>From [e-mail] (Malcolm H. Teas)
Date: 17 Apr 1996 13:08:42 GMT
Organization: Blaze Technology, Inc.

In article <DaveZ-1604960803590001@msn_7_2.binc.net>
[e-mail] (David B. Zwiefelhofer) writes:

> > Once your temp. block is there, use SetZone() to designate it as the
> > current heap zone.  Call GetZone() before hand to get your current app
> > zone first, so you can restore things later.
> >
>
> Actually, I've learned that you need to call InitZone first, then SetZone.

Uh, sorry.  Good point, I forgot that.

> I do use the temporary memory for much longer than one loop, but I do
> unlock it before each call to WaitNextEvent.

As you're using temp. memory to allocate a temporary heap, you *don't*
want to unlock it!  Heaps have pointers in them.  If your temp. heap
floats, those pointers will be bad & your program will crash.  Just
allocate it, move it high, and lock it down till you're done with it
and ready to deallocate it.

Glad to hear it's going well.

Malcolm  H. Teas                E-Mail: [e-mail]
Blaze Technology, Inc.          Telephone: [phone]
PO Box 200279                   Fax: [phone]
Austin, TX USA 78720-0279       WWW: http://www.btech.com/
   ** A Macintosh software development services company  **

+++++++++++++++++++++++++++

>From [e-mail] (Scott Squires)
Date: Wed, 17 Apr 1996 07:51:54 -0800
Organization: Puffin Designs

In article <DaveZ-1604960803590001@msn_7_2.binc.net>,
[e-mail] (David B. Zwiefelhofer) wrote:

 >I would use just TempNewHandle if I could, but I need to call routines
>such as NewGWorld that are allocated in the current heap, so I don't have
>much choice.
>


Just pass 'useTempMem' as a GWorldFlag to NewGWorld.


-scott


Scott Squires               "Insert funny stuff here"
[e-mail]
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (AndrewWelc)
Date: 17 Apr 1996 11:30:29 -0400
Organization: America Online, Inc. (1-800-827-6364)

> As you're using temp. memory to allocate a temporary heap, you *don't*
> want to unlock it!  Heaps have pointers in them.  If your temp. heap
> floats, those pointers will be bad & your program will crash.  Just
> allocate it, move it high, and lock it down till you're done with it and
> ready to deallocate it.

This is exactly what I did in a project I worked on recently... and it
crashed/froze on certain machines.  To recap:  I allocated a temporary
block of memory, locked it down, and then called InitZone() on it.  I was
careful about preserving the proper heap zone, etc.

To this day, I can't figure out what was going wrong.

+--------------------------------------------------------------+
|    Andrew Welch - Thaumaturgist - Ambrosia Software, Inc.    |
+-------------------------------+------------------------------+
|    AOL-> Keyword: Ambrosia    |  http://www.AmbrosiaSW.com/  |
|    CIS-> GO word: Ambrosia    |   ftp://ftp.AmbrosiaSW.com/  |
+-------------------------------+------------------------------+


+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 18 Apr 1996 09:45:29 GMT
Organization: Ecole Normale Superieure, Paris

In article <DaveZ-1104961918360001@msn_3_16.binc.net>,
David B. Zwiefelhofer <[e-mail]> wrote:

>3) Anything else relevant to using temporary heaps.

- Try to avoid it. Although there are Memory Manager functions
  to do it, it is discouraged by Apple. A previous version of
  one of my programs used to create a heap inside a temporary
  block and work in there. This caused no end of compatibility
  problems with Virtual Memory, RAM Doubler and various functions
  like RecoverHandle() which didn't behave correctly. My current solution
  is to allocate large blocks in the temporary heap (for instance, by
  passing the useTempMem flag to NewGWorld) and small blocks in the
  application heap, and conflicts have disappeared.

- If you must do it, be aware that there is a new, undocumented
  function in the Modern Memory Manager called DisposeZone. I think
  you should call it when you destroy your private zone. This is
  because the MMM keeps a list of all existing zones for use by
  RecoverHandle() and the list will become corrupted if you don't
  call it.

Hope this helps,

--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Abrahamson)
Date: Thu, 18 Apr 1996 10:47:12 -0400
Organization: PDI

In article <4l52vp$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <DaveZ-1104961918360001@msn_3_16.binc.net>,
> David B. Zwiefelhofer <[e-mail]> wrote:
>
> >3) Anything else relevant to using temporary heaps.
>
> - Try to avoid it. Although there are Memory Manager functions
>   to do it, it is discouraged by Apple. A previous version of
> [snip]

Just to be clear, is the issue as follows:

   1. Temporary *heaps* are discouraged.

   2. Allocating blocks of temporary memory (multi-finder memory) is ok.

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 18 Apr 1996 16:15:29 GMT
Organization: CoBase group, UCLA Department of Computer Science

In article <4l32ql$[e-mail]>, [e-mail] (AndrewWelc) writes:
> > As you're using temp. memory to allocate a temporary heap, you *don't*
> > want to unlock it!  Heaps have pointers in them.  If your temp. heap
> > floats, those pointers will be bad & your program will crash.  Just
> > allocate it, move it high, and lock it down till you're done with it and
> > ready to deallocate it.
>
> This is exactly what I did in a project I worked on recently... and it
> crashed/froze on certain machines.  To recap:  I allocated a temporary
> block of memory, locked it down, and then called InitZone() on it.  I was
> careful about preserving the proper heap zone, etc.
>
> To this day, I can't figure out what was going wrong.

If it was crashing while you were disposing of the temporary heap zone
(or exiting your program) you were probably bitten by the MMM. There is
a dispose call, the counterpart of InitZone(), which you need to call
when disposing of a heap zone. (If memory serves, it's called DisposeZone().)

The only place I have seen this 'documented' was in the Kon & Bal column
of _Develop_ a couple of issues ago (I'm away from my Mac at the moment,
so I can't look it up for you, :-( but it's there somewhere.) The gist of
it was that _most_ of the time the MMM can figure out when a block is a
heap zone, but not always. You might try giving that a look or appealing
to a higher authority.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (AndrewWelc)
Date: 18 Apr 1996 13:19:01 -0400
Organization: America Online, Inc. (1-800-827-6364)

> If it was crashing while you were disposing of the temporary heap zone
> (or exiting your program) you were probably bitten by the MMM. There is
a
> dispose call, the counterpart of InitZone(), which you need to call when
> disposing of a heap zone. (If memory serves, it's called DisposeZone().)

That sounds like something which makes sense.  Ugh.  Undocumented, eh?  I
think I know why it may not have been able to figure out that those blocks
were heap zones.  I padded the heap block a tad... may have confused the
MMM.

What do your calls to InitZone() look like?


+--------------------------------------------------------------+
|    Andrew Welch - Thaumaturgist - Ambrosia Software, Inc.    |
+-------------------------------+------------------------------+
|    AOL-> Keyword: Ambrosia    |  http://www.AmbrosiaSW.com/  |
|    CIS-> GO word: Ambrosia    |   ftp://ftp.AmbrosiaSW.com/  |
+-------------------------------+------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 19 Apr 1996 07:48:12 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Jeff Abrahamson <[e-mail]> wrote:
>Just to be clear, is the issue as follows:
>
>   1. Temporary *heaps* are discouraged.
>
>   2. Allocating blocks of temporary memory (multi-finder memory) is ok.

That's what I meant. I seem to recall hearing an Apple engineer
warning against private heaps in this newsgroup, and indeed my
practical experience has told me they caused compatibility
problems. Temporary blocks, on the other hand, are entirely OK. It's
even OK to keep them locked, even though everybody will warn you
against it ;-) (I know, I know, I shouldn't)

--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Vincent Nonnenmacher)
Date: Fri, 19 Apr 1996 18:22:21 +0200
Organization: DPI

In article <4l32ql$[e-mail]>,
[e-mail] (AndrewWelc) wrote:

>> As you're using temp. memory to allocate a temporary heap, you *don't*
>> want to unlock it!  Heaps have pointers in them.  If your temp. heap
>> floats, those pointers will be bad & your program will crash.  Just
>> allocate it, move it high, and lock it down till you're done with it and
>> ready to deallocate it.
>
>This is exactly what I did in a project I worked on recently... and it
>crashed/froze on certain machines.  To recap:  I allocated a temporary
>block of memory, locked it down, and then called InitZone() on it.  I was
>careful about preserving the proper heap zone, etc.
>
>To this day, I can't figure out what was going wrong.
>

I had exactly the same trouble, I haven't figured out either was
was wromg the program runs fine witout the new memory manager.

I tested under QC, validating everything and I haven't found anything
bad or any word from Apple to 'discourage' people doint this !

They just said it is improper to make assumption about the document
Heapzone header just that, and anyway this header is initialized
by the InitZone call.

So Mr Apple if ewMemory manager is not supporting new heaps or
Heaps inside heaps please let us know !!!!!!!!

Vincent Nonnenmacher


Vincent Nonnenmacher

DPI SA
116 AV DE LA REPUBLIQUE
38320 BRESSON
(33) 76 33 25 06    fax [phone]

+++++++++++++++++++++++++++

>From Andrew Welch <[e-mail]>
Date: Fri, 19 Apr 1996 17:40:33 -0500
Organization: Ambrosia Software, Inc.

Christopher Larson wrote:

> If it was crashing while you were disposing of the temporary heap zone
> (or exiting your program) you were probably bitten by the MMM. There is
> a dispose call, the counterpart of InitZone(), which you need to call
> when disposing of a heap zone. (If memory serves, it's called DisposeZone().)

Here's the code I was using... if anyone sees something wrong with it, I'd love to hear
it...

// -------------------------------------------------------------------------------
// -- Create a heap zone in temporary memory

THz CreateTempHeapZone(long zoneSize)
{
Handle    tempHandle;
THz        result;
OSErr    err;

tempHandle = TempNewHandle(zoneSize, &err);
if ((tempHandle) && (err == noErr))
    {
    HLock(tempHandle);
    if (MemError() == noErr)
        {
        Ptr        limit, start;
        short    index;
        THz        oldZone;

// -- Initialize the heap zone

        result = (THz)(*tempHandle);
        start = StripAddress((Ptr)(*tempHandle));
        limit = start + zoneSize - 4;

        oldZone = GetZone();
        InitZone(nil, 32, limit, start);
        SetZone(result);

        for (index = 0; index < NUM_HEAP_MASTERS; index++)
            MoreMasters();
        SetZone(oldZone);
        }
    }

return result;
}    // -- CreateTempHeapZone


// -------------------------------------------------------------------------------
// -- Dispose a heap zone in temporary memory

void DisposeTempHeapZone(THz theZone)
{
Handle    tempHandle;

tempHandle = RecoverHandle((Ptr)theZone);
if (tempHandle)
    {
    DisposeHandle(tempHandle);
    }
}    // -- DisposeTempHeapZone


+--------------------------------------------------------------+
|    Andrew Welch - Thaumaturgist - Ambrosia Software, Inc.    |
+-------------------------------+------------------------------+
|    AOL-> Keyword: Ambrosia    |  http://www.AmbrosiaSW.com/  |
|    CIS-> GO word: Ambrosia    |   ftp://ftp.AmbrosiaSW.com/  |
+-------------------------------+------------------------------+


+++++++++++++++++++++++++++

>From [e-mail] (Dave Warker)
Date: Sat, 20 Apr 1996 11:59:17 -0400
Organization: Express Access Online Communications, USA

If you dig back in the develop issues, I believe there was a discussion
in, of all places, the Puzzle Page (and some folks say it doesn't teach
anything) about the problems with temporary heaps. It all boils down to
the fact that there is no DisposeZone() call and therefore the memory
manager doesn't always know when to remove a heap from its list of active
heaps.

I suppose it could inspect every DisposePtr() and DisposeHandle() call to
see if the released memory contains a heap, but that is an awful lot of
overhead.

In article <DaveZ-1604960803590001@msn_7_2.binc.net>, [e-mail]
(David B. Zwiefelhofer) wrote:
> I do use the temporary memory for much longer than one loop, but I do
> unlock it before each call to WaitNextEvent.

If you mean the handle containing the temporary heap, allowing it to move
would definitely cause problems since the memory manager expects heaps to
stay put.

Dave

--
Dave Warker
     mailto: [e-mail]
     http://www.acy.digex.net/~dwarker/


+++++++++++++++++++++++++++

>From [e-mail] (Malcolm H. Teas)
Date: 22 Apr 1996 19:41:18 GMT
Organization: Blaze Technology, Inc.

One thing that would help reduce fragmentation in your Process Manager
heap (where temp. memory is allocated) is to call MoveHHi() on the
block before it's locked.  This isn't critical in most cases though.

I don't see anything really terrible here.  Note that the MoreMasters()
loop (in theory) can be replaced by upping the second parm to
InitZone().

I'm guessing, as a result of this code, that the problem isn't in
creating the zone, but using it.

Malcolm  H. Teas                E-Mail: [e-mail]
Blaze Technology, Inc.          Telephone: [phone]
PO Box 200279                   Fax: [phone]
Austin, TX USA 78720-0279       WWW: http://www.btech.com/
   ** A Macintosh software development services company  **


---------------------------

End of C.S.M.P. Digest
**********************